做一次“打折”的可用性测试

我们都知道可用性测试能够帮助我们及时发现问题，让我们做出更符合用户需求的产品，也能让自己的方案更有说服力。但你可能也听说过一次完整的可用性测试所需要的成本也是不菲的，我们需要招募用户、撰写测试脚本、制作测试原型，还需要有记录设备、有经验的主持人、用户奖品等。

专业完整的可用性测试固然能更好地发现问题，但也会消耗更多的时间和资源。就像《Don’t Make Me Think》作者说的那样，做一次“打折”的可用性测试其实也能达到不错的效果。最近我在做一个功能模块的优化，已经出了新方案的原型，但是不太确定它能否很好地解决问题，就和产品经理商量一起组织一次简单的可用性测试，发现收获还蛮大的。

用这篇文章记录一下这次可用性测试的过程，也算是自己的思考总结。

明确目的

无论是交互设计师还是产品经理，我们在做任何方案之前最重要的事情就是要明确目的。这次测试也不例外，我们希望能够通过对被试者的行为分析来了解该设计方案是否比现有设计好，能不能够解决问题，还有没有优化空间。

准备原型

其实这一次想到要进行测试时，原型已经做好了。但为了达到更好的效果，我们又特别制作了一个高保真可交互的原型以供测试。在原型中我们都是尽量找来现有产品中的真实数据，以保证被试者有代入感。

招募用户

一般可用性测试需要寻找产品的真实用户，但这需要提前招募，还要预约时间，会比较久。因为公司平时都在使用自己的产品，所以我们就准备从其他各部门招募几个同事来进行测试。这样的话，可以节约很多时间。

不过需要注意的是，在邀请之前也需要和对方讲清楚这次测试将会耗时多久，问他们有没有时间，毕竟这会影响到对方的工作。

一般对于外部用户，可用性测试是需要支付一定报酬或者奖励的。这一次虽然我们邀请的是同事，也还是要给他们一些小礼物表示感谢，因为每个人的时间都是宝贵的。这一点在测试之前我没有想到，还好产品经理准备了一些小礼物，当然也不用太贵重，一些零食什么的就可以啦。

撰写测试脚本

接下来就是撰写测试脚本。由于我没有经验，撰写的测试脚本很长，而且不符合真实场景，导致在测试时不是很顺畅。因此我总结了两条建议：

• 控制任务数量
  在进行任务设计时一定要控制好总量，太短得不到好的结果，太长会导致被试者失去耐心。这次测试我就犯了“任务设计过多”的错，导致有几个被试者在看到任务列表时就被吓到了。

• 任务应该符合真实场景
  在进行任务设计时，应该保证这些任务是连贯的，符合真实场景的。我在设计任务时为了保证每一个点都能被测到，设计的任务没有连贯性，也不符合真实使用场景，导致一些被试者看不懂任务。

正式测试

接下来就到了我们的重头戏——正式测试，正式测试其实包括前中后三个阶段。

测试前

在测试之前，需要准备好两台电脑和一间安静的会议室。一台电脑做测试之用，提前安装好录屏软件（推荐 ScreenFlow ，可以同时录屏录音），并将测试原型打开。另一台电脑显示测试任务，方便被试者浏览。

测试前人员分工也很重要，需要定义一名主持人和一名观察者，主持人引导被试者进行测试，观察者用纸笔记录被试者的行为。大家一定要提前分工明确，以保证测试正常进行。

测试中

测试中，主持人需要先简短介绍测试背景，以及一些注意事项。需要注意的是，主持人在测试时不应该引导被试者，如果被试者问自己该如何操作，也应该告诉他先自己摸索，直到进行不下去时才可以适当说明。

主持人可以在测试时使用“思考发声法”，发声思考法是指：引导被试者一边操作，一边说出心里的想法。这样可以实时地了解被试者的真实想法，以免在最后访谈时被试者忘记了当时的想法。

测试后

测试完成后，主持人和观察者应该及时访谈被试者，了解他们的一些想法。此时观察者也可以就自己记录的内容进行提问，以便后面的分析。

分析输出

在最后，我们应该将所有资料汇总，分析总结这其中遇到的一些问题。根据分析结果，总结出问题的重要性，进行方案优化。如果时间允许，甚至还可以使用优化的原型再做一次测试。

总结

这次测试我们尽量简化，从原型制作到测试分析只用了三天左右的时间，但是发现了很多问题，收获很大。对于这一次可用性测试，我还从中总结了以下几点：

• 预测试不能省略，预测试能够让我们提前发现问题，让正式测试更加流畅

• 测试前一定要和被试者说明我们测的是产品的问题，而不是人，让被试者放松下来

• 当你的原型太过于高保真时，应该告诉被试者这只是原型，否则他们会当成真实产品

• 除了获得一个更好的设计方案，这也是一个和同事增进交流的机会

推荐阅读：